Configuring distributed applications using object decomposition in an atomic action environment

A common technique for constructing reliable distributed applications is to use atomic actions for controlling operations on persistent objects. Atomic actions are used to ensure that inconsistencies in application state do not arise when failures occur or when concurrent activities operate on shared objects. Within such an application, objects provide a convenient unit for distribution and concurrency-control. The properties of atomic actions and objects can be exploited together to configure distributed applications, without affecting the correct functioning of the application. This leads to the possibility of changing the configuration of concurrency and distribution of the distributed application to improve availability and performance. These changes in concurrency and distribution can be achieved by varying the object decomposition within the application. In this paper, we show how some kinds of reconfiguration can be achieved without any modification to client applications. The observations are a result of constructing reliable distributed applications using the Arjuna system, which provides tools and libraries for programming with atomic actions and persistent objects in C++. 1 . Introduction One of the major concerns in the construction of reliable applications in a distributed environment to do with the maintenance of the consistency of an application's state, despite the failure of components (hardware or software). One technique, which has been used successfully for constructing particular classes of reliable distributed applications, is the use of atomic actions [1]. Applications which have been found suitable for the use of atomic action are those which must process complex operations on persistent data concurrently, such as: banking systems and airline seat reservation systems. One way of structuring applications using atomic actions, which has been advocated by many research projects, for example, Argus [2], Arjuna [3], Avalon/C++ [4], Clouds [5] and ANSA [6], is for atomic actions to operate on persistent objects. Persistent objects being objects which still exist after the application which created them has terminated. When constructing such an application, two of the most critical sets of design decisions that need to be made are: * Appeared in the Proceedings of the IEE Workshop on Configurable Distributed Systems, London, March 1992 i) Atomic action structure: How should the operations of the application be decomposed into atomic actions? Should a number of atomic actions be grouped within an enclosing atomic action (nesting)? Which atomic actions can be run concurrently? Which atomic actions must finish before others can be started? ii) Object decomposition: How should the application's state be decomposed into objects? Which objects should be decomposed into sub-objects? What operations do the objects have? Should a sub-object be independently concurrency-controlled, or should the concurrency-control applied to the container object also control access to (all of the) subobjects? On which node should each object reside? Some aspects of the behaviour of such applications, such as performance and availability, can be altered by changing the atomic action structure and/or the object decomposition. These alterations in the configuration of the application should not affect the correct functioning of the application. However, apart from minor changes in the scope of an atomic action, the atomic action structure cannot generally be changed without altering the semantics of the application. Hence, there is little scope for re-configuration by modification of the action structure. This paper is focused on describing the kinds of changes that can be made to the object decomposition of the application, which do not alter the correct functioning of the application. These changes to the object decomposition can be used to reconfigure the concurrency and distribution of the application thereby improving its overall availability, reliability, or performance. 2 . Atomic actions Distributing applications creates new opportunities which are not always available in centralised applications. Such applications can be designed to utilize the concurrency inherent in a distributed environment. Also, distributed applications can take advantage of the fact that the failure of a single hardware component is unlikely to cause the complete failure of the distributed environment. These opportunities con also give rise to problems for the designers of an application. The concurrency within an application must be managed to ensure the application's state remains consistent. Component faults that cause part of the distributed environment to fail could also give rise to inconsistencies in an application's state unless steps were taken to prevent them. Atomic actions provide a mechanism which addresses these two problems. Atomic actions aid maintenance of a consistent application state due to their properties of: Serialisability: Concurrently executing atomic actions do not interfere with each other (i.e., their concurrent execution will produce the same effect as some serial order execution). Failure atomicity: Atomic actions will either terminate normally (commit), producing the intended effects or producing no effects (abort). Permanence of effect: Any effects produced by an atomic action which has terminated, are not lost due to later component failures. Atomic actions can be combined with other fault tolerance mechanisms to cope with a wide range of failures, such as hardware and software design errors, but in the rest of this paper, we consider the use of atomic actions only to tolerate fail-stop faults i.e., faulty components are silent, and operations performed in isolation in the absence of any faults will be regarded as always producing consistent state changes. Given that an application is constructed using atomic actions which perform certain operations, it is sometimes necessary to combine these atomic operation sequences to form larger operation sequences, which are also required to be atomic [7]. The resulting larger atomic action's effects being some combination of the effects of the atomic actions from which it is composed. The atomic actions which are contained within the resulting atomic action are said to be nested, and the resulting action is referred to as the enclosing atomic action. The enclosing atomic action is sometimes referred to as the parent of the nested or child atomic action. The outermost atomic action in an atomic action structure is called a top-level atomic action. Nested atomic actions differ from top-level atomic actions in that the effects of a nested atomic action will be recovered if the enclosing atomic action aborts, even if the nested atomic action has committed. This is required to ensure the failure atomicity of the enclosing atomic action. Also, to maintain the serialisability of the enclosing atomic action, the locks obtained by the nested atomic actions which commit, must be inherited by their enclosing atomic action. Figure 1, shows a pictorial representation of an enclosing atomic action A which contains the nested atomic actions B and C, where atomic action B must be completed before atomic action C can be started.